Introduction
The Leightweight Directory Access Protocol (LDAP) is a protocol used to facilitate the communication with directory services such as OpenLDAP or Active Directory. These act as repositories for user information by storing credentials, users, groups, etc. Because of this, LDAP can also be used for the authentication and authorisation of users.
What makes LDAP easy to use is that it operates with its data in a plain text format called the LDAP Data Interchange Format (LDIF).
This protocol works on TCP port 389. Its secure variation (LDAPS) runs on TCP port 636 and establishes a TLS/SSL connection.
Data Organisation
Information within LDAP has a hierarchical tree structure called the Directory Information Tree (DIT). This structure is flexible and there are no real restrictions to the way its levels are organised. The root of the tree is usually the domain which LDAP operates in. This domain is then split into domain components (dc) at each . character. From then on, you are more or less free to organise your DIT in any way you like.
The LDAP DIT can be distributed across multiple directory servers which do not even need to be based in the same physical country.
Entities
LDAP stores its data in the form of entities. These are instantiated from objectClasses, which are just templates for making the creation of entities easier.
An entity is comprised of attributes. These are key-value pairs with the possible "keys" (attribute names) being predefined by the objectClass that the entity is an instance of. Furthermore, the data stored in the attribute must match the data type defined for it in the objectClass.
Setting attributes is done by separating the name and value by a colon:
mail: jdoe@cyberclopaedia.com
When this attribute is later queried (but not set), an "equals" sign is used instead.
mail=jdoe@cyberclopaedia.com
An example user entity displayed in LDIF could be:
dn: sn=Doe,ou=users,ou=employees,dc=cyberclopaedia,dc=com
objectclass: person
sn: Doe
cn: John Doe
Distinguished Name (DN) & Relative Distinguished Name (RDN)
The full path to an entity in LDAP is specified via a Distinguished Name (DN). A Relative Distinguished Name (RDN) is a single component of the DN that separates the entity from other entities at the current level in the naming hierarchy. RDNs are represented as attribute-value pairs in the form attribute=value, typically expressed in UTF-8.
A DN is simply a comma-separated list of RDNs which hierarchically follows the path to the LDAP entry. For example, the DN for the John Doe user would be dc=local,dc=company,dc=admin,ou=employees,ou=users,cn=jdoe.
The following attribute names for RDNs are defined:
| LDAP Name | Meaning |
|---|---|
| DC | domainComponent |
| CN | commonName |
| OU | organizationalUnitName |
| O | organizationName |
| STREET | streetAddress |
| L | localityName |
| ST | stateOrProvinceName |
| C | countryName |
| UID | userid |
It is also important to note that the following characters are special and need to be escaped by a \ if they appear in the attribute value:
| Character | Description |
|---|---|
space or # at the beginning of a string | |
| space at the end of a string | |
, | comma |
+ | plus sign |
" | double quotes |
\ | backslash |
/ | forwards slash |
< | left angle bracket |
> | right angle bracket |
; | semicolon |
LF | line feed |
CR | carriage return |
= | equals sign |
LDAP Filters
Filters are logically meaningful combinations of attribute-value pairs of the format which must be encapsulated in (). The value may be replaced by an asterisk (*) in order to match any objects which simply have that attribute, regardless of what its value is.
As already demonstrated, LDAP filters are represented as strings. Therefore, any characters that have special meaning in LDAP must be escaped if they are used as a literal part of an attribute name or value:
| Character | Escape Sequence |
|---|---|
( | \28 |
) | \29 |
* | \2a |
\ | \5c |
| null character (must always be escaped) | \00 |
Presence Filters
The simplest possible filter is the presence filter which matches all objects that have a certain attribute regardless of its value. It has the format (attribute=*). For example, the filter (objectClass=*) is often used to match all entries because any entry must have at least one objectClass.
Comparison Filters
These filters are a bit more complex and involve the comparison of the attribute's value with some desired value.
The simplest of these is an equality filter which checks if the attribute has a certain value. It has the format (attribute=value). For example, the filter (objectClass=user) will return all objects which have an objectClass of User.
Greater-or-Equal and Less-or-Equal filters will match an object if it has at least one value for the specified attribute that is >= or <= to the provided value, respectively. They are constructed in the same way as equality filters but use >= or <= in lieu of the equal sign. The way the comparison is done depends on the data type. For example, attributes whose values are expected to be numbers will use numeric comparison, while strings will be compared lexicographically. For some attributes comparisons like this may not even make sense and thus these filters cannot be used with them. For example, it doesn't make sense to say that the colour blue is greater than red or vice versa.